1. Technical Field
This application relates to UMTS (Universal Mobile Telecommunications System) in general, and to an apparatus and method for handling cell update during reconfiguration in universal mobile telecommunications system user equipment in particular.
2. Description of the Related Art
UMTS is a third generation public land mobile telecommunication system. Various standardization bodies are known to publish and set standards for UMTS, each in their respective areas of competence. For instance, the 3GPP (Third Generation Partnership Project) has been known to publish and set standards for GSM (Global System for Mobile Communications) based UMTS, and the 3GPP2 (Third Generation Partnership Project 2) has been known to publish and set standards for CDMA (Code Division Multiple Access) based UMTS. Within the scope of a particular standardization body, specific partners publish and set standards in their respective areas.
Consider a wireless mobile device, generally referred to as user equipment (UE), that complies with the 3GPP specifications for the UMTS protocol. The 3GPP 25-331 specification, v.3.15.0, referred to herein as the 25-331 specification, addresses the subject of UMTS RRC (Radio Resource Control) protocol requirements between the UMTS Terrestrial Radio Access Network (UTRAN) and the UE.
In accordance with clause 8.2.2.3 of the 25-331 specification, the UTRAN may send a reconfiguration command to the UE. The reconfiguration command includes an activation time that specifies when the reconfiguration should be applied, which can be either immediately or at some time in the future, generally up to a maximum of 2.55 seconds in the future, although usually expected to be only a few milliseconds in the future. The reconfiguration procedure is considered to be ongoing until the UE replies with a response message, which would normally be sent from the UE at or shortly after the activation time.
This procedure is illustrated in FIG. 1. A Reconfiguration command is sent from the UTRAN to the UE, with a new configuration X. The requested new configuration X, typically a dedicated physical channel, is applied at both the UE and the UTRAN at the activation time, indicated by the dotted line. The new configuration is generally applied at the UE before sending a Reconfiguration_COMPLETE response. If the reconfiguration fails for any reason, the UE will revert to its previous configuration and send a Reconfiguration_FAILURE message indicating that the reconfiguration has failed.
However, if an event occurs that requires a cell update to be invoked while the reconfiguration procedure is ongoing, the current 3GPP standards do not unambiguously define the required behaviour of the UE, so potentially leading to interoperability problems. Events requiring a cell update to be invoked are defined in clause 8.3.1.2 of the 25-331 specification and include the conditions of radio link failure, re-entering service area, RLC unrecoverable error, cell reselection and periodical cell update.
The basic cell update procedure is illustrated in FIG. 2. On the occurrence of a trigger event, the UE moves into the cell_FACH state and sends a CELL UPDATE request message to the UTRAN, which tracks the state of the UE. The UTRAN returns a CELL UPDATE CONFIRM (Y) message, where Y represents the reconfiguration carried by the CELL UPDATE CONFIRM message. Both the UTRAN and UE apply the new configuration Y and the UE sends a response to the UTRAN, confirming the completion of the reconfiguration procedure. When the procedure completes, the UTRAN knows both the state of the UE and its current configuration (FACH+Y), as required to maintain communication.
In addition to the general interaction of the cell update and reconfiguration procedures, two other scenarios need to be taken into account when designing UTRAN behaviour. The first is the crossover of the CELL UPDATE command with the Reconfiguration command, while the second is the cell update occurring while the Reconfiguration_COMPLETE message is in transit. The first of these is illustrated in FIG. 3 and the second in FIG. 4.
FIG. 3 illustrates the situation where a Reconfiguration command is issued by the UTRAN but reaches the UE after the UE has sent the CELL UPDATE command to the UTRAN. In this case, the Reconfiguration command is rejected per clause 8.6.3.11 of the 25-331 specification. Therefore, nothing happens at the activation time and both the UE and UTRAN apply the cell update configuration Y. The UE then sends a confirmatory response message and a Reconfiguration_FAILURE message to the UTRAN. FIG. 3 demonstrates that it is sensible for the UTRAN not to apply the reconfiguration (X) during the cell update, but to wait until after the cell update completes. If it applies X on receipt of the cell update response message, it must revert to the previous configuration when it receives the Reconfiguration_FAILURE message.
FIG. 4 illustrates the situation of a cell update occurring while the Reconfiguration_COMPLETE message is in transit. The UTRAN issues a Reconfiguration (X) command with an activation time. This is received by the UE and the configuration X is executed at the activation time. Subsequently, the UE issues a Reconfiguration_COMPLETE message. However, before this message reaches the UTRAN, an event occurs which triggers transmission of a CELL UPDATE command to the UTRAN. Because a C-RNTI is required to send the Reconfiguration_COMPLETE message (See 9.2.1.1.c of the 3GPP 25-321 specification) and this may not be available until the CELL UPDATE CONFIRM is received, the Reconfiguration_COMPLETE message cannot be sent until the cell update completes. The UTRAN must therefore tolerate receiving a response to the Reconfiguration command after completion of an intervening cell update.
The present invention aims to propose strategies for dealing with the interaction of a cell update procedure with a reconfiguration that has already started. A number of such strategies are detailed below, denoted B0 to B6.